Conversation
|
Tests? :P or later, after the discussion has been resolved? it just seems worth ensuring that |
|
Ah, very good point. I did my testing in the context of Yes, after discussion is the perfect time to add tests. |
|
So I'm going soon to publish a package for macropy, @Technologicat do you care to add a test or two for this? |
|
Sure! I'll add some tests and push them, probably later today. |
…sing mechanism; now kwargs is a dict, {name_as_str: ast_node}
|
Done, test added. It gets picked up by While at it, I made the mechanism a bit more user-friendly: since the keyword arg name is always a string constant, the value is now automatically extracted from the The way the user macro implementation sees it, the parameter This separation is important when the Inside the implementation, I changed the name I'm not sure if the Anything else? :) |
|
Ping? Anything that still remains to be done? |
3 participants
My kwargs hack related to issue #13, mainly for discussion for now.
In this version:
**kw, calledkwargs.kwargsgets the AST, as alistofast.keywordobjects, of named arguments passed to the macro invocation.mac(a0, ..., an, k0=v0, ..., km=vm)[body]; thekj=vjpairs are new. Similarly for block and decorator macros (just the placement ofbodydiffers).The named args are kept completely separate from the MacroPy
**kwarguments, to protect MacroPy internals, and to prevent shadowing (in either direction). This captures only the user-given named args (e.g.x=1) in kwargs.This complete separation is very important for the use of kwargs as syntax for binding constructs. Otherwise, e.g. a
letconstruct might try to bind the namegen_sym(similarly for other MacroPy internals) because it happens to have an entry in**kw.IMHO, the already existing args and the proposed kwargs together form one complete feature, namely the use of all the possibilities offered by Python's function call syntax, to provide extra slots for ASTs to be fed into the macro invocation beside the single body.
Also IMHO, this fixes an asymmetry in the MacroPy API. Already, macros can be given positional args, but no named args from the use site. (The existing implementation silently ignores named args, which I think is just an oversight; it should at least raise an error if we don't want to support named args. But that's really a separate issue.)
The body can of course already be a tuple, or really anything, so the whole feature does not add any fundamental capability - but it provides some flexibility for the syntax macros can offer to the user. For example, let constructs look more readable with a syntactically separate bindings block, which naturally takes one of the forms
let((x, 1), (y, 2))[body]orlet(x=1, y=2)[body]. I think the latter is more pythonic.Thoughts?